Cache invalidation with partial key knowledge #87
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…te function against a key comparison.
|
+1 I am evaluating this library to replace an internal library that is non-core compatible wrapping HttpRuntime.Cache I was reviewing the issues and code for the remove method to check for this compatibility and you beat me to it :) |
|
+1 |
|
This is very similar to the newer #153 (and has the same issues) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per the issue I opened just a brief while ago at #86, this pull request is a first pass at an implementation supporting cache invalidation without knowing the entirety of the key.
Since it requires knowledge of the various keys in the cache, I implemented a non-authoritative list of keys that attempt to update along with the various cache operations, but also thus allow for a predicate function to iterate through each of the keys for matches based on partial key knowledge.
This enables a scenario where I have a user identified by a value and want to cache the result of an operation based on the values of any of the parameters to the method. The current LazyCache implementation easily supports the addition of keys to this end, but should I modify any of the data, I may want to invalidate all keys referencing this user even though that identifier is only part of a larger composite.
My pull request enables the user to define a Func that iterates through all the keys that are presumably in the cache to select those to remove, despite lacking the information necessary to produce the whole cached key. I'd appreciate any feedback you have about this.